Writing the Development Process Portfolio

How to turn analysis, design and development into a case study C10-2 can be marked from. Read it before class write 2.

Note

The bands this serves. C10-2, 5–6: evaluates the use of the analysis, design and development stages. 7–8: critically evaluates the process … from start to finish … and how this process assisted in meeting requirements. 9–10: discusses and justifies improvements that could be made … by approaching the stages differently. Describing what you did stops at 3–4.

flowchart LR
    A["Analysis<br/>what I discovered<br/>about the problem"] --> RA["retro<br/>went well ·<br/>was tricky ·<br/>next time"]
    RA --> B["Design<br/>how I planned<br/>the solution"]
    B --> RB["retro<br/>went well ·<br/>was tricky ·<br/>next time"]
    RB --> C["Development<br/>how I built<br/>the solution"]
    C --> RC["retro<br/>went well ·<br/>was tricky ·<br/>next time"]
    RC --> D["Evaluation<br/>how the three stages<br/>helped me meet<br/>the requirements"]

The retrospectives are not decoration between the stages — they are the material the final evaluation is built from. Skip them and stage 4 has nothing to evaluate.

What is this?

Your development story - a case study showing how you navigated the PSM stages, made critical decisions, and learned from challenges.

Purpose: Tell the story of your journey through analysis → design → development, showcasing critical thinking and lessons learned.

📖 Write Your Development Story

Think Case Study, Not Checklist

Instead of: "I completed analysis stage"
Write: "During Week 2 analysis, I discovered users actually needed X when I assumed they needed Y, so I updated my requirements and interviewed 3 more users..."

🎯 Story Structure (C10-2)

Stage 1: Analysis - "What I discovered about the problem"

Your Narrative:

The investigation: How did you research the problem?
Key discoveries: What surprised you about user needs?
Decision moments: When did you change direction and why?
Problem-solution pairs: Challenge you hit → How you solved it

Evidence to Include:

Research notes with captions: "This interview revealed users needed offline mode"
Meeting minutes/user feedback
Requirements evolution screenshots

Mini-Retrospective:

What went well?
What was tricky?
Action for next time: "Next project I'll prototype earlier"

Stage 2: Design - "How I planned the solution"

Your Narrative:

Design evolution: Show how designs changed and improved
Choice explanations: "I chose React over vanilla JS because..."
Alternative paths: What other designs did you consider?
User feedback integration: How did feedback shape your design?

Evidence to Include:

"Before" and "After" mockups showing evolution
Decision logs with reasoning
Annotated wireframes: "Changed button layout after usability feedback"

Mini-Retrospective:

What went well?
What was tricky?
Action for next time:

Stage 3: Development - "How I built the solution"

Your Narrative:

Technical journey: Key coding decisions and challenges
Problem-solving moments: "When I couldn't get the API to work, I..."
Tool choices: Why you picked specific technologies
Scope adjustments: How you handled changing requirements

Evidence to Include:

Git commit examples with context: "This commit fixed the login bug discovered in testing"
Code snippets with explanations
Bug fixes with problem-solving rationale

Mini-Retrospective:

What went well?
What was tricky?
Action for next time:

Stage 4: Evaluation - "How PSM helped me succeed"

Your Analysis:

PSM effectiveness: How did each stage contribute to meeting requirements?
Critical thinking moments: Key decisions that shaped the project
Process improvements: What would you do differently?
Professional growth: What did this process teach you?

📁 Portfolio Format Ideas

Timeline-Based Story:

Week-by-week narrative with artifacts and reflections at each stage

Visual Case Study:

Annotated screenshots/mockups with decision explanations and lessons learned

Problem-Solution Journey:

Organize around major challenges faced and how you solved them

Decision Tree Format:

Show key decision points with reasoning and outcomes

📊 Evidence + Reflection Template

PSM Stage	Key Evidence	What I Learned	Next Time I'd..
Analysis	Research notes, user interviews	Users needed offline mode	Interview users earlier
Design	Wireframes, mockup evolution	Simple designs work better	Get feedback on every iteration
Development	Git commits, code solutions	Testing early saves time	Set up automated testing from start
Overall	Complete journey reflection	PSM stages prevented major rework	Plan for more user feedback loops

✨ Pro-tips:

Tell YOUR story - Include personality, choices, and real experiences

Show evidence with context - Each artifact needs a caption explaining why it matters

Be honest about struggles - Challenges overcome demonstrate critical thinking

Connect to requirements - Explain how your process helped meet FR/NFR

Use visuals - Screenshots, diagrams, timelines make it engaging

🎯 Remember:

This isn't about having a perfect process - it's about demonstrating thoughtful reflection on your development journey and showing what you learned along the way!

Check Your Understanding

1. Which of these two sentences can reach band 7–8, and why? (a) "I completed the design stage, producing mock-ups and a data dictionary." (b) "Designing the data dictionary before coding meant the save-file format was settled early, so the two save bugs found in alpha testing were format bugs, not design bugs."

Answer

(b). It evaluates the use of the stage — it says what the stage did for the project and ties it to a requirement being met. (a) outlines what was produced, which is band 3–4 territory.

2. Band 9–10 asks you to justify improvements by approaching the stages differently. Why is "I would have coded faster" not enough?

Answer

It is not a change to a stage. An answer that opens the band names a different way of running analysis, design or development — prototyping before finalising the SRS, say — and then justifies it against something that actually went wrong.

3. Every artefact you include needs a caption. What must the caption say?

Answer

Why the artefact matters — the decision it evidences — not what it is. "Wireframe v2" is a label; "Changed the button layout after two testers missed the hold control" is a caption.